J2EE - what, if anything, does it mean to Bugzilla??
jpyeron at pyerotechnics.com
Thu Dec 4 08:38:28 UTC 2003
So this is what happens when I am not at my computer...
[to find my responses search for $$$$]
On Wed, 3 Dec 2003, Joel Peshkin wrote:
> Anybody have an idea of what a J2EE shop expects from its applications?
> Must they all be WRITTEN in J2EE or is it an API?
> Is there anything in particular that could make Bugzilla more friendly
> to a J2EE shop??
$$$$ Short answer, they want J2EE compliance http://java.sun.com/j2ee/
J2EE is a methodology of programming, it covers RPC, Persistence,
Data-Modeling, N-tier application development. J2EE is more a design
pattern than anything else.
There are many tools/API implementations which are use in a J2EE
environment. A "J2EE" shop will most likely have IDEs (JBuilder, etc.),
App-servers (Websphere, Weblogic, etc.), developers familiar with Beans,
Corba, UML, Java, (other languages via JINI)
any we organized "shop" will eat what they make, that means they will be
using tools which support live code inspection, and tools which can reside
on their (expensive) app-servers.
This means a marketable tool for a "J2EE shop" should conform to the
Enterprise Bean Design patterns. (implies java?, don't know a ways around
this other than lots of CORBA stuff)
On Wed, 3 Dec 2003, J. Paul Reed wrote:
> On 03 Dec 2003 at 21:55:15, Bruce Armstrong arranged the bits on my disk
> > They'd want it written in Java, preferrable using
> > servlets or something similar (i.e., Scarab).
> J2EE doesn't read XML?
Yes, a JavaBean, with a front end in a Servlet would be most
J2EE is a design pattern, there are API's which read XML (xerces, etc..)
On Wed, 3 Dec 2003, J. Paul Reed wrote:
> On 03 Dec 2003 at 22:21:21, Bruce Armstrong [TeamSybase] arranged the bits on$
> > It's not a matter of whether it reads XML or not. If
> > they're going to maintain it, customize it, etc.,
> > they're going to want it in the language they're
> > already fluent in (i.e., Java). It also means they
> > would be able to deploy it into their existing
> > infrastructure (their J2EE/JSP servers).
$$$$ I don't think that most organizations will "maintain it" other than via
a web interface. That said being able to give a "WAR" (web archive, more
following) to the it people to put up on the App-server (they don't have
'web' servers) is the only way for them. Most of our clients don't have the
capability to put up a new machine or add software to their existing
A war is a JAR following special design patterns. there is a special
directory called WEB-INF inside it there are "private" details like
configurations of users, a web.xml (like httpd.conf), code, libraries,
etc. A war is designed such that it can be compiled (like tar czf) once
and then be deployed/installed on any server.
A jar is a ZIP based archive, POSIX compliant version I think.
> Then they don't want Bugzilla, plain and simple. Assuming you just wanted
> something to interface in certain clearly defined ways with Bugzilla, then
> getting information via XML for display in a J2EE application should work
> just fine.
> But if you're doing anything else, then don't use Bugzilla. I don't
> understand this preoccupation some people have with wanting to use
> Bugzilla, but in some other language.
$$$$ I tend to think of Bugzilla as a design, not the Perl code. So when
someone asks for Bugzilla on there app server which only runs 'Java'
applications, they DO STILL want Bugzilla.
If you allow for the possibility of constrained resources then asking to use
XML/RPC to a machine running Apache w/Perl is a inappropriate. This is the
basis for the "preoccupation". Almost all of our clients refuse to do
something a different way, for some reason they think is a good one.
> There's already a Java-based bug tracker if you want that (Apache uses it,
> I guess). You (meaning Joel, I guess) should also talk to Jason (see bug
$$$$ as far as bug 188570, we are working full steam on it, but it changed
course a little bit. I have decided that there seems to be to much anti
java sentiment to produce something useful to the bugzilla community. That
said we have taken the bugzilla schema, and some long term goals of bugzilla
(security, security, security, customization, ISO 9001, etc..) and
targeted it at that (BZ 3.0?). Once done we are going to port/track it to
Perl as a (set of?) module. [we are not so much concerned with reports, charts,
etc...) I am going to make a separate email for this...
Yes, I am asking to be flamed there, please be gentle.
On Wed, 3 Dec 2003, Bruce Armstrong [TeamSybase] wrote:
> FWIW, I understand it quite a bit. People want to
> work with a language that they're fluent in. And a
> number of people out there (myself included) are much
> more fluent in other langauges than they are in Perl.
> --- "J. Paul Reed" <preed at sigkill.com> wrote:
> > I don't understand this preoccupation some people
> > have with wanting to use Bugzilla, but in some
> > other language.
> Bruce Armstrong [TeamSybase]
$$$$ I think that is a moot point, the current developer community has
precedent here. It is a Perl project, with Perl resources invested (us,
the developers), the client (us the users) demands a high quality product.
there is no guarantee that here will be same caliber/quantity of resources
for an other language. this means that expected quality may falter, hence
we the customers would be very dissatisfied.
that said it is further inappropriate to ignore more resources and large
client base (maybe larger?, at least more money)
- Jason Pyeron http://www.pyerotechnics.com -
- Partner & Sr. Manager Pyerotechnics Development, Inc. -
- +1 (443) 451-2697 500 West University Parkway #1S -
- +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 -
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
More information about the developers