Re: [JBoss-dev] Servlet Spec Question

[philipborlin]

Let me see if I understand correctly:

In my web.xml I would put:

  
...
  


In my web containers proprietary descriptor file I would put:

  
  ...


So when I deploy, the container will match up the extra description
information in my proprietary descriptor with the element in the web.xml
based on the id?

Thanks,
-Phil



   
   
  Jules Gosnell <[EMAIL PROTECTED]>
   
  Sent by:   To:  [EMAIL 
PROTECTED] 
  [EMAIL PROTECTED] cc:
  
  ceforge.netSubject: Re: 
[JBoss-dev] Servlet Spec Question   
   
   
   
   
  05/28/03 05:53 AM
   
  Please respond to
   
  jboss-development
   
   
   
   
   




I've seen what I think was this at work in a WebSphere descriptor...

The idea is that you can unambigously identify any element in the
standard dd, by adding an 'ID="xxx"' attribute, then in your proprietary
dd you can add further information about that element and use the ID to
unify the two descriptions.

Some things in the standard dd already have unique names (servlets
etc..), some things may not and thus the vendor might need recourse to
this mechanism.

Jetty, AFAIK, does not make use of this,


Jules


[EMAIL PROTECTED] wrote:

>I am working on a deployment plugin for JBoss IDE and had a question about
>the servlet spec (I was reading 2.3).  On pages 112-116 it describes an ID
>mechanism so that tools can provide additional deployment information.  I
>don't really understand what it is talking about.  Does anyone have an
>example of how these are used?  Do Jetty and Tomcat have different
>non-standard depoyment information?
>
>Thanks,
>-Phil
>
>Here is a portion of the spec I was referencing.  It is several pages so I
>have just reprinted the beginning:
>
>
>
>
>
>
>
>
>[snip]
>
>
>
>
>---
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>___
>Jboss-development mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>




---
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development







---
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Servlet Spec Question

[philipborlin]

I am working on a deployment plugin for JBoss IDE and had a question about
the servlet spec (I was reading 2.3).  On pages 112-116 it describes an ID
mechanism so that tools can provide additional deployment information.  I
don't really understand what it is talking about.  Does anyone have an
example of how these are used?  Do Jetty and Tomcat have different
non-standard depoyment information?

Thanks,
-Phil

Here is a portion of the spec I was referencing.  It is several pages so I
have just reprinted the beginning:








[snip]




---
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] JDT compiler was: php5 is coming

[philipborlin]

JDT stands for Java Development Tools and is a subproject of the Eclipse
framework.  I looked through the source a bit and it looks like the main
compiler class is org.eclipse.jdt.internal.compiler.Compiler.  I found the
source in my plugins directory of Eclipse (no additional download needed)
under the directory org.eclipse.jdt.source_2.1.0/src in the jdtcoresrc.zip.

The only problem is that this is an "internal" package which means that
there is neither binary nor api contracts between releases.  The Eclipse
project committers seems to tend to try to open the API's to everyone once
they stabilize, so if someone puts a little pressure on them, they might be
willing to move this class out of the internal package.

There is a method in the Compiler class with the signature:
public void compile(ICompilationUnit[] sourceUnits)

This looks like the method that would be most useful.  The ICompilationUnit
interface isn't the most basic interface in the world.  There are quite a
few methods, but a look through the compiler code may give clues to which
methods are necessary.  This interface doesn't really care where your java
code came from so it would definately meet the criteria for an in memory
compiler.

The other obstacle is the constructor to the Compiler class.  It requires
quite a few interfaces to be fleshed out.  The signature is:
public Compiler(INameEnvironment environment, IErrorHandlingPolicy policy,
Map settings, final ICompilerRequestor requestor, IProblemFactory
problemFactory)

It really doesn't look like this was meant to be used outside of the larger
JDT framework, but might be worth the trouble if other alternatives don't
look so good.

-Phil



   
   
  "Scott M Stark"  
   
  <[EMAIL PROTECTED]>To:  <[EMAIL 
PROTECTED]>   
  Sent by:   cc:   
   
  [EMAIL PROTECTED] Subject: Re: Re[2]: [JBoss-dev] php5 
is coming   
  ceforge.net  
   
   
   
   
   
  04/01/03 02:04 PM
   
  Please respond to
   
  jboss-development
   
   
   
   
   




I don't know what JDT is. It was not I who suggested it. The JDT
page says: http://www.eclipse.org/jdt/index.html

 The JDT project provides the tool plug-ins that implement a Java IDE
supporting the development of any Java application,
including Eclipse plug-ins. It adds a Java project nature and Java
perspective to the Eclipse Workbench as well as a number of
views, editors, wizards, builders, and code merging and refactoring tools.
The JDT project allows Eclipse to be a development
environment for itself.

Not obviously an in memory compiler, but maybe in there somewhere.


Scott Stark
Chief Technology Officer
JBoss Group, LLC


- Original Message -
From: "julien viet" <[EMAIL PROTECTED]>
To: "Scott M Stark" <[EMAIL PROTECTED]>
Sent: Tuesday, April 01, 2003 11:45 AM
Subject: Re[2]: [JBoss-dev] php5 is coming


> what is supposed to be eclipse JDT ?
>
> SMS> So get another compiler. We don't need no stinking JSR.
>





---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Eclipse with HEAD and 3.2 opened at same time?

[philipborlin]

Just use Check Out As... to check out HEAD and name it something like
"JBoss HEAD".  Next, just use Check Out As... again and check out the 3.2
branch into something like "JBoss 3.2".  That way both branches can be in
the same workspace at the same time.

-Phil



   
   
  Jason Dillon <[EMAIL PROTECTED]> 
 
  Sent by:   To:  [EMAIL 
PROTECTED] 
  [EMAIL PROTECTED] cc:
  
  ceforge.netSubject: Re: 
[JBoss-dev] Eclipse with HEAD and 3.2   
 opened at same time?  
   
   
   
  03/09/2003 02:57 AM  
   
  Please respond to
   
  jboss-development
   
   
   
   
   




Starting two instances is a pain in the ass on OS X :-(

--jason


On Sunday, March 9, 2003, at 08:51 AM, Igor Fedorenko wrote:

> What do you want to do? Won't two Eclipse instances do?
>
>> -Original Message-
>> From: Jason Dillon [mailto:[EMAIL PROTECTED]
>> Sent: Saturday, March 08, 2003 5:02 PM
>> To: [EMAIL PROTECTED]
>> Subject: [JBoss-dev] Eclipse with HEAD and 3.2 opened at same time?
>>
>>
>> Does anyone one if it is possible to get eclipse two have JBoss HEAD
>> and JBoss 3.2 opened at the same time?
>>
>> --jason
>
>
> ---
> This SF.net email is sponsored by: Etnus, makers of TotalView, The
> debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost
> and
> disoriented. TotalView can help you find your way. Available on major
> UNIX
> and Linux platforms. Try it free. www.etnus.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger

for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development







---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Eclipse is so amazing...

[philipborlin]

> I think it is better to use the jars from the module output directory,
> cause the exact location under build/output will change from version to
> version.

What build/output will change from version to version?

> Is there any way to make Eclipse create jars?

Go under the file menu to export.  Choose jar file and follow the wizard.

> Or any way to make it conditionally compile stuff for 1.3 and others for
1.4?

Right click on a project and go to properties.  Select Java Compiler on the
left.  If you click on the "Use project settings" radio button then you can
set any custom compiler options you want including setting the compiler
compliance level (1.3 or 1.4).

> Or a way to force it to use ant to do all compiles?

Right click on your project and go to properties again.  Click on External
Tools Builders.  Click on the New... button and select Ant Build.  On the
build options tab you can specify if you want to have this run for Full
builds, Incremental builds, and/or Auto builds.

-Phil




---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Eclipse is so amazing...

[philipborlin]

Starting with M5 (I can't remember if it was in M4) you can do a check out
into... which will allow you to choose a source folder to check out into.
If you right click on your project, choose properties and then Java Build
Path there is a source tab where you can add new source directories.  Next
go into your CVS perspective and do the check out into... and point the new
module to the source directory of your choice.  You will have to do this
for every module but a) all the modules will be in one project and b) you
only have to do this once.  After that you will have the seemless single
project CVS access you were looking for.

-Phil



   
   
  "Nathan Phelps" <[EMAIL PROTECTED]>  

  Sent by:   To:  <[EMAIL 
PROTECTED]>   
  [EMAIL PROTECTED] cc:
  
  ceforge.netSubject: RE: 
[JBoss-dev] Eclipse is so amazing...
   
   
   
   
  02/26/2003 02:00 PM  
   
  Please respond to
   
  jboss-development
   
   
   
   
   




Are you using the internal extssh client?  I can certainly check out the
source on the command line then connect the checked out source project
by project.  However, I was sort of hoping to be able to checkout a
whole branch from within Eclipse AS a project.  In other words, I was
really hoping to do:

1.) Open the CVS Repository Explorer
2.) Right-click on a project Branch (having already set up the branch
stuff) and choose "Check out as Project"
3.) Switch to the Java Project and start working.

As it stands right now, this simply doesn't work (especially with
Branch_3_2).

Thanks,

Nathan

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jason Dillon
Sent: Wednesday, February 26, 2003 2:26 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Eclipse is so amazing...

Any reason not to set it up as multiple projects?  I have had nothing
but success when connecting Eclipse projects to a checked out
jboss-head.

--jason


On Thursday, February 27, 2003, at 02:42  AM, Nathan Phelps wrote:

> While we're on the subject of Eclipse...
>
> Can anyone give me some tips for working with the JBoss source in
> Eclipse via the built-in extssh client?  I can get it all checked out,
> but then it gets very confused about the package names.  It tries to
do
> j2ee.src.main.org.jboss.j2ee, messaging.src.main.org.jboss.mq, etc.  I
> guess it wants individual projects for each directory?
>
> I was hoping to set it up as a SINGLE project so I can just check out
> the source and start working.  I read the "The Developing JBoss using
> Eclipse HOWTO," but it only explores setting it up as multiple
> projects.
> This question is echoed on the forums as well at
> http://www.jboss.org/forums/thread.jsp?forum=162&thread=28822.
>
> Up to now I've been using NetBeans, but I'd really like to get this up
> and running on Eclipse with the JBoss IDE plug-in and all if possible.
>
> Thanks,
>
> Nathan
>
>
>
> ---
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>



---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This 

RE: [JBoss-dev] Metadata Service

[philipborlin]

If you are interested in XPath check out
http://jakarta.apache.org/commons/jxpath/index.html which has an XPath
implementation that will work with (quote from site) "JavaBeans, Maps,
Servlet contexts, DOM etc, including mixtures thereof. "

-Phil




   
 
"Matt Munz" <[EMAIL PROTECTED]> 
 
Sent by:   To: 
 
[EMAIL PROTECTED]
<[EMAIL PROTECTED]>
eforge.net cc: 
 
   Subject: RE: 
[JBoss-dev] Metadata
   Service 
 
11/13/2002 01:30 PM
 
Please respond to jboss-development
 
   
 
   
 




Bill,

> My thinking is that a "well-crafted object graph or relational db" needs
to
> be crafted and the code maintained.  Most components in JBoss are
configured

Well, so do DTDs and XML schemas.  It is an interesting argument that an
XML
Document object is a more flexible construct than a given arrangement of
Data Objects (Hashtables, lists), and POJOs.  I suppose the primary point
is
that an XPath query is more easily maintained than a given set of method
calls.  It certainly avoids the compiler, but so does the JMX bus, which
does not use an XML document object as its metadata database...

> via XML files.  Why not store this XML in memory with Xerces? XML Objects
> provide us with a common, simple, easy way to store config data in memory
> and reference it(XPath).

Sure.  But don't the XML Objects eventually get converted into Objects?
Why
not keep those Objects in memory?

For the objects that end up as MBeans, perhaps an enhanced search mechanism
for the MBean Registry would be another way to address the problem?

  - Matt

-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Bill
Burke
Sent: Wednesday, November 13, 2002 2:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Metadata Service



> BTW -- I aggree that XPath is cool.  What makes a "central" XML file work
> better as a metadata database than a well-crafted object graph or
> relational
> database, in your opinion?

My thinking is that a "well-crafted object graph or relational db" needs to
be crafted and the code maintained.  Most components in JBoss are
configured
via XML files.  Why not store this XML in memory with Xerces? XML Objects
provide us with a common, simple, easy way to store config data in memory
and reference it(XPath).

>Is there something specific to this metadata
> problem that makes a "central" XML file a more attractive solution?
>

I saying Document as in the Java Object.  Not in a XML file stored on disk.

>   - Matt
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Bill
> Burke
> Sent: Wednesday, November 13, 2002 2:02 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Metadata Service
>
>
> 1. I'm not talking about a central config file...Components register
their
> XML with this service.  MBean, EJB, whatever...
>
> 2. You know what XPATHs are right?  If not, look them up.  They are
really
> cool.  Xerces/Xalan (forget which) support looking up Elements via
XPATHS.
> What's not supported, which we would have to write, would be the
> ability to
> register for change notifications via an XPATH.
>
> Other ideas:
> - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc.
> Services/components registered as listening for changes, recieve
> notification.
>
> - JMX console needs an additional XML editor for MBean attributes that
are
> XML elements.
>
> - This sort of centralized service allows you to query, via
> XPATHS, for all
> components that have a "port" attribute for instance.  Allows you to do
> global things on configuration when you don't know the actual components
> that have that type of attribute
>
> Another thing about configuration I wanted to have is the concept of
> Configuration Domains.  A component would get configuration by searching
a
> set of chained configuration domains.
>
> invocation domain->instance domain->component domain->app server
> domain->cluster domain etc...
>
> So, when a component needs config information, it looks it up

Re: [JBoss-dev] jboss modules as eclipse projects

[philipborlin]

Right click on an xml file and the popup menu will have an option called
"Run Ant...".

-Phil



   
 
[EMAIL PROTECTED] 
 
Sent by:   To: 
 
[EMAIL PROTECTED]
[EMAIL PROTECTED]  
eforge.net cc: 
 
   Subject: Re: 
[JBoss-dev] jboss modules   
   as eclipse projects 
 
08/18/2002 04:56 AM
 
Please respond to jboss-development
 
   
 
   
 




Anyone got eclipse to execute ant-buildfiles? Where do you specify the
build.xml file to be executed?

On Sun, Aug 18, 2002 at 10:59:32AM +0200, Werner Ramaekers wrote:
> Hi Igor,
>
> i am very interested to know what changes you had to make and how you
> went along to be able to develop jboss (and not apps on jboss) from
> within Eclipse,
> can you mail me what you had to do ? or just post it onto the list so
> that anyone else interested can pick it up too ;-)
>
> thanks for sharing
>
> Werner
>
> Igor Fedorenko wrote:
>
> > Hi,
> >
> > I have setup eclipse project for most of jboss modules. It required
> > some changes to one of build.xml files but now I can use eclipse as a
> > convenient jboss source code browser or (theoretically) start jboss
> > under eclipse debugger. Anyone interested?
> >
>
> --
> --
> ir. Werner Ramaekers
> Enterprise Java Solutions Architect - Shift@
> Sun Certified Java Programmer
>
> "May the source be with you."
>  
> --
>
>
>
>
>
> ---
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development

--
MVH
Marius Kotsbak
Boost communications AS


---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development






---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment

[philipborlin]

Dain wrote:
> ServicePort contains a hostName, port, and InetAddress.

Doesn't InetAddress contain the hostName?

-Phil


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Dropping the System.out calls in the jmx code

[philipborlin]

Can't we just create a special org.apache.log4j.Category (and later
org.apache.log4j.Logger) and make it so none of the methods do anything.
We could make it so the factory methods simply return our degenerate
Category.  This would make the smallest possible log4j distribution for
embedded use.

-Phil



   
 
"marc fleury"  
 
<[EMAIL PROTECTED]>To: 
 
Sent by:   
<[EMAIL PROTECTED]>
[EMAIL PROTECTED]cc: 
 
eforge.net Subject: RE: 
[JBoss-dev] Dropping the
   System.out calls in the 
jmx code 
   
 
05/02/2002 09:00 AM
 
   
 
   
 




The idea of a "logger" in an embedded system is kind of strange, what are
you going to log to ??? I mean most of the time is your embedded chip going
to lug around a 50Gig barracuda IDE??? no... are you going to open an
socket
just for "logging"... no... are you going to fill your memory (tight if we
believe specs) with "log" message... no.

Logging in J2ME (JBoss4.0) strikes me as a DEBUGGING feature.  Useful while
in development. Then YES you want to know what is going on, that much is
trivial to see.

This is where log4j becomes interesting, we would essentially DISABLE it
for
use in production J2ME while keeping it on for development but the code
remains the same.  So the port to log4j is interesting in that respect.

So the question for you JBoss4.0 fans out there is how small can we get
log4j to be to do NOTHING, i.e. redirect all messages to /dev/null but
still
keep the code the same in our JBossMX/JBoss layers.

marcf


|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Adrian Brock
|Sent: Thursday, May 02, 2002 7:05 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Dropping the System.out calls in the jmx code
|
|
|Making the JBossMX logger use log4j is easy enough.
|The only problem is log4j isn't configured until
|after the MBeanServer is created in ServerImpl.
|This isn't a big problem since the loggers are designed
|to boot with System.err and swap over to the required
|logging implementation when it becomes available.
|
|There are also some places in the code that do
|System.out directly that need fixing.
|
|I'll do this at the weekend.
|
|I'm was also looking at reducing the footprint for
|embedded, while allowing functionality to be added later.
|My early attempt isn't very good. The footprint is
|9k compared with 2k for common's Logger.
|
|Regards,
|Adrian
|* * *
|
|View thread online:
http://jboss.org/forums/thread.jsp?forum=66&thread=14612

___

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


___

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development





___

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] IBM Public License

[philipborlin]

Peter (Braswell) and I were looking at UDDI implementations for jboss.net
and the best one so far is UDDI4j.  It is under the IBM Public License and
we weren't too sure what the differences between licenses are.  Is IBM's
license open source enough for JBoss?

-Phil


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Re: on the use of final

[philipborlin]

I want to hear your message on "visibility".

-Phil



   
  
"marc fleury"  
  
<[EMAIL PROTECTED]>To: "Luke Taylor"   
  
Sent by:   
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
"Jboss-Development@Lists. Sourceforge. Net"   
eforge.net 
<[EMAIL PROTECTED]> 
   cc: 
  
   Subject: RE: 
[JBoss-dev] Re: on the use   
11/28/2001 08:30 AMof final
  
   
  
   
  






|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Luke
|Taylor
|Sent: Wednesday, November 28, 2001 10:14 AM
|To: Jboss-Development@Lists. Sourceforge. Net
|Subject: Re: [JBoss-dev] Re: on the use of final
|
|
|Dain Sundstrom wrote:
|
| > There are like five hundred rules on that page. What is it specifically
| > flagging as a bad practice?  I am actually interested.
| >
|
|I had a look at the page too (try searching for the word "final" :-).
|But it doesn't really seem say more than the obvious "Helps compiler
|optimization and more clearly documents the use of classes" ... So it
|can be helpful for people reading the code to know that it has no
|subclases, but it's not really a big deal.
|
|Together also has some QA rules relating to the use of final. One is
|that *all* instantiated classes should be final. The others just seem to
|relate to constant attributes which seems fair enough.

sounds like bulls to me

one day I will send a message on "visibility" (public/protected/private),
basically it is useless, and other OO-weewee-touching people will argue
about for hours but I got real work to do :)

marcf

"The wallpaper pattern"
-- Some guys at DrKW --

|
|Luke.
|
|--
|  Luke Taylor.  Monkey Machine Ltd.
|  PGP Key ID: 0x57E9523Chttp://www.mkeym.com
|
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development





___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] suggest changing log4j layout patterns

[philipborlin]

I think that all the extra information will confuse new JBoss users.  If a
person is advanced enough to want to debug components within JBoss they
will be advanced enough to edit the log4j properties themselves.

-Phil



   
  
Jason Dillon <[EMAIL PROTECTED]>  
  
Sent by:   To: 
  
[EMAIL PROTECTED]
<[EMAIL PROTECTED]> 
eforge.net cc: 
  
   Subject: 
[JBoss-dev] suggest changing 
   log4j layout patterns   
  
11/15/2001 05:09 PM
  
   
  
   
  




I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:

For console:

   "%-5p %c{1} [%t] - %m%n"

INFO  JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate

For server.log:

   "%d %-5r %-5p %c [%t] (%x) - %m%n"

2001-11-13 11:35:32,210 2396  INFO  org.jboss.util.Shutdown [main] () -
Shutdown hook added
2001-11-13 11:35:36,576 6762  WARN
org.jboss.configuration.ConfigurationService [main] () -
Monitor:name=BeanCacheMonitor does not implement any Service methods

 * * *

I have found that the extra information is very, very useful to debug
components running inside of JBoss.  The above puts the minimal amount of
useful information on the console in a terse format and dumps all usefull
information into server.log in a verbose format.

I believe that users of JBoss would benifit from these settings by default
and I suggest that we update the log4j.properties (or use log4j.xml) with
these layout formats.

Any objections?

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development





___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] RH: tools.jar (javac)...

[philipborlin]

Maybe I am missing something, but isn't this whole issue about distributing
a compiler with JBoss so the user doesn't have to download the JDK and edit
a configuration file to point to it?

If that is the case, can't we distribute jikes?

-Phil



   
  
"Scott M Stark"
  
<[EMAIL PROTECTED]>To: "JBossDev 
\(E-mail\)" 
Sent by:   
<[EMAIL PROTECTED]> 
[EMAIL PROTECTED]cc: 
  
eforge.net Subject: Re: 
[JBoss-dev] RH: tools.jar
   (javac)...  
  
   
  
11/13/2001 05:37 PM
  
Please respond to "Scott M Stark"  
  
   
  
   
  




That is how both the bundled tomcat and standalone tomcat handles this.
You have to have the JDK tools.jar, or jikes, or some other compiler
configured
as part of the installation. Since we can't bundle tools.jar and javac.jar
is
just a black box we don't want to include since it source for it can't be
obtained,
there is nothing we can do to make this a platform independent zero
configuration issue as far as I know.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: "David Maplesden" <[EMAIL PROTECTED]>
To: "JBossDev (E-mail)" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 4:14 PM
Subject: RE: [JBoss-dev] RH: tools.jar (javac)...


> No I haven't and I see now what you mean, I didn't read what you put
> carefully enough.  Still you might be able to do it this way, IIRC we
used
> to distribute javac in a javac.jar that was distributed with JBoss to
> different platforms and it seemed to work OK.
>
> I thought the only reason we weren't distributing tools.jar in the same
way
> is because of licensing issues with Sun.
>
> That of course brings up a problem with 1) you can't distribute any
package
> you create that contains tools.jar (I think).
>
> Perhaps the easiest thing to do for the Jetty dist is to reference
tools.jar
> as if it exists in the lib/ext dir and simply include a README telling
> people what is going on, then they can supply their own (platform
specific
> if neccessary) jar.
>
> David
>
> > -Original Message-
> > From: Julian Gosnell [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 14, 2001 1:02 PM
> > To: David Maplesden; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
> >
> >
> > David Maplesden wrote:
> >
> > > 1) worked fine for me...
> >
> > Have you tried it on different architectures?
> >
> > My concern is that if I do the build on Linux, the tools.jar
> > from my 1.3.1
> > distrib may not work on e.g. a Mac etc...
> >
> > Jules



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development





___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] package level fields

[philipborlin]

I think that the rationale behind making all your fields private is that
nobody can break design and access those fields.  If you have a specific
design reason why a field needs to be accessed directly then you can open
up your field to allow access.  Better yet is to control access through an
accessor or mutator.  The idea that I am going to make my field  just so that I can make it easier to extend goes against
all good object-oriented principles that I have ever studied.  I tend to
agree with the original poster (and the Ant team for that matter).

-Phil



   
  
Jason Dillon <[EMAIL PROTECTED]>  
  
Sent by:   To: 
  
[EMAIL PROTECTED]
<[EMAIL PROTECTED]> 
eforge.net cc: 
  
   Subject: Re: 
[JBoss-dev] package level
   fields  
  
08/03/2001 02:25 PM
  
Please respond to jboss-development
  
   
  
   
  



> Does anyone know why all of the fields in org.jboss.ejb.Application are
> declared with package (default) access?  Most of the classes that I have
> looked at in org.jboss.ejb have fields with package access.  If there is
not
> a good reason,  I suggest that we make these private as this helps to
> prevent spaghetti code.

I do not think there is a strong reason for it.  Though I would not suggest
private for classes which we might expect folks to want to extend from
(unless there are getter/setter methods for the appropriate fields).

Private access is great where private access should be applied, though it
looks like many folks like to just make everything private (like most of
the
stuff from the ant project) which makes it very, very, very hard to
customize and such.

I think it would be good to use private or protected where package private
is not required.  I would just be careful not to make everything private,
where it might not be appropriate.

--jason


___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development





___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development