[9] We name interfaces with a 'I' at the beginning of them...
Is this point about Java interfaces or conceptual interfaces?
For example, PageFlowConstants is a Java interface, but not really an
'interface' in my opinion. While constants inside of PageFlowConstants
may be part of the API
The I naming convention is applied to only Java interfaces like:
public interface IFoo {...}
It's not meant to be used on abstract base classes -- which aren't
interfaces -- just an API.
It's really meant to make very obvious in code what is and is not an
interface without having to
Obviously, we are pretty split in the code base. I think the majority
of the interfaces inside NetUI use the 'I' and outside of NetUI there
may not be any. I think we should just punt on this one and say
consistency within a set of code overrides consistency across
Beehive. New interfaces
This whole thread is a good argument for why you should just use the
standard Sun/Java conventions without mods... I think you'll end up
in a long debate over the mods where no one is ever satisfied.
Coding conventions are just too much about style and thus, there is no
right or wrong to
I think we are pretty close to agreement, though we haven't heard from
a lot of people. I think the biggest source of debate is code changes
(like renaming interfaces and variables). This may be style, but
there are code changes in public APIs that would be required to match
this spec.
On
I agree... we're amazingly close to agreement (compromise) here. The
only snag we've run into is the I prefix, and it sounds like we're OK
with *not* mandating it at this point. Beyond that, does anyone else
object to any of the other mods we've made (or to the whole idea)?
Daryl Olander
I agree, it is important to make sure the WSDL-JCX mapping
functionality is fully tested.
Looking at the ExtensionMaker class in the webservice control it
appears that it is using wsm to load and provide the model for the the
wsdl, it then emits the jcx by traversing that model. Are there
Restructure the webservice contol's drt area to make tests easier to add
Key: BEEHIVE-798
URL: http://issues.apache.org/jira/browse/BEEHIVE-798
Project: Beehive
Type: Test
Versions: TBD
Seems right to me. Enumerating where we are right now:
- follow Sun Java coding conventions except for:
- line length of 100 or 120 characters
- allow use of _ for naming class-level variables
- allow declaration before use of variables
- use todo instead of fixme
- nix the I naming
Oh, yeah -- Wiki page here once we've come to general agreement:
http://wiki.apache.org/beehive/CodingConventions
On 6/8/05, Eddie ONeil [EMAIL PROTECTED] wrote:
Seems right to me. Enumerating where we are right now:
- follow Sun Java coding conventions except for:
- line length
[ http://issues.apache.org/jira/browse/BEEHIVE-798?page=all ]
Chad Schoettger updated BEEHIVE-798:
Attachment: build.xml.patch
Patch for this fix:
The following files need to be moved/removed/added:
basedir is:
Also:
[2.2] adjust the list to README.txt (Jeremiah)
[3.1.1] adjust to the current ASF header (Jeremiah)
[4] explicitly defined indentation as 4 spaces (Jeremiah)
[7.4] newline before else (Daryl)
[7.9] newline before catch (Daryl)
[10.5.1] Make an exception for and || -- no
[ http://issues.apache.org/jira/browse/BEEHIVE-798?page=all ]
Chad Schoettger updated BEEHIVE-798:
Attachment: README.txt
add new file README.txt
Restructure the webservice contol's drt area to make tests easier to add
Schemas should be in the distribution
-
Key: BEEHIVE-799
URL: http://issues.apache.org/jira/browse/BEEHIVE-799
Project: Beehive
Type: Improvement
Versions: V1
Reporter: John Rohrlich
Priority: Minor
I went
I agree with the following items. I think the others need more
discussion. It would be better to start a new thread for the other
issues to reach closure on them independently, Unless there is an
objection to it, I will start them later today.
- tight coupling between the build-time and
[
http://issues.apache.org/jira/browse/BEEHIVE-717?page=comments#action_12313080
]
daryoush mehrtash commented on BEEHIVE-717:
---
Thanks eddie for the commit and the Asserts you added improved the code, well
except this one (line 82 on Control
Hi all:
Concerns and questions concerning (1):
A system very similar to proposal (1) was in place for the v1-alpha release.
One complaint about it at the time was that Javadoc-generated HTML pages were
being checked in to SVN. I am not sure how the current proposal (1) avoids
this drawback.
[
http://issues.apache.org/jira/browse/BEEHIVE-717?page=comments#action_12313093
]
Eddie O'Neil commented on BEEHIVE-717:
--
Daryoush--
Hey, so the reason I changed that is because of the comment Should not happen,
just being paranoid.
In general,
- the role of the .ser file seems to be to preserve a metadata shape
that was computed from the JWS file itself. Since this file available
at both build and run time, it seems to make sense to recompute
(once!) at runtime so that the .ser files aren't necessary. But, I
don't have the
Steve--
Comments in line.
Eddie
On 6/8/05, Steve Hanson [EMAIL PROTECTED] wrote:
Hi all:
Concerns and questions concerning (1):
A system very similar to proposal (1) was in place for the v1-alpha release.
One complaint about it at the time was that Javadoc-generated HTML pages were
Yes, I believe that there is a third option. :)
Today, we've got two options:
1) require .java source files be built with debug on so that the
parameter names are available
2) use the .ser files which are serialized Java objects of type
BeehiveWsTypeMetadata
The first is pretty good --
On 6/8/05, Daryoush Mehrtash [EMAIL PROTECTED] wrote:
.ser file exist for one reason and one reason only. JSR 181 says that
name of a @WebParam by default is:
Name of the parameter as it appears in the argument list.
The issue is that this name gets lost after the class is
I feel debug option is a good one. It would require us to resurrect the old
reflection code from the SVN.
I like to view JWS as a façade to a web service and since we only require the
debug to be turned on for the JWS files, any performance impact of having
debugged turned on should be
In WSM we don't generate any source code, so far .ser has been our
only artifact that we generated.
If we want to go the route of generating any file, a XML file might be a
better option.
daryoush
-Original Message-
From: Kyle Marvin [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
- remove the unused classes HandlerHandler, AxisTypeRegistrar,
AxisTypeMappingUtil, DebugPrintMessageHandler, WSDLProcessor,
InvalidFileType, XmlBeanTypeMappingUtil,
HandlerHandler, InvalidFileType are not used any more.
DebugPrintMessageHandler, I think is being used but can go
Yeah -- if at all possible, it seems good to avoid generating code
in the WSM case just because we don't need to, though it's a good
point -- I'd forgotten controls did that.
But, it could definitely work either way. A source code file seems
easier to deal with than a serialized object for
Hm. Somehow, I'd missed AxisTypeRegistrar is used by the service
control, but I'd not seen that these files:
AxisTypeMappingUtil
WSDLProcessor
XmlBeanTypeMappingUtil
are used in the service control. Can you describe how? I've got them
deleted and WSM and the service control build and pass
On 6/8/05, Daryoush Mehrtash [EMAIL PROTECTED] wrote:
In WSM we don't generate any source code, so far .ser has been our
only artifact that we generated.
If we want to go the route of generating any file, a XML file might be a
better option.
Early (pre-Beehive) versions of the Controls
- does anyone know the status of XMLBean type handling in WSM?
This is an easy one! It works. But needs more testing, I am
particularly concern about case when we are working with documents from
different namespaces and schema files..
Our WSM and Service Control samples demonstrate it
Good catch. I had a comment on the earlier response but thought this
would confuse the issue at this point and removed it before I send my
message.
A little background.The Registration process is used when you
register a Java class to the underlying type system. The TypeMapping
utils are
[
http://issues.apache.org/jira/browse/BEEHIVE-717?page=comments#action_12313100
]
daryoush mehrtash commented on BEEHIVE-717:
---
In this case I think we should not do assert. You do have a good point on
Asserts in general.
minor
Let me preface this by saying that updating the live site is currently a
medium-sized pain in the neck that will become a large-size pain when multiple
versions of Beehive arrive.
More concerns about (1):
That said, I don't think we should checkin Javadoc-generated
[
http://issues.apache.org/jira/browse/BEEHIVE-717?page=comments#action_12313112
]
Eddie O'Neil commented on BEEHIVE-717:
--
Okay, so, we'll remove the check (assert and conditional) entirely then? Or is
this an expected case that needs to be
[
http://issues.apache.org/jira/browse/BEEHIVE-717?page=comments#action_12313117
]
daryoush mehrtash commented on BEEHIVE-717:
---
my suggestion is to remove the assert leave the code in.
minor non-conformance of exceptions to JSR-181 / JAX-RPC
Lots of good points here; I'll see if I can address them in-line.
On 6/8/05, Steve Hanson [EMAIL PROTECTED] wrote:
Let me preface this by saying that updating the live site is currently a
medium-sized pain in the neck that will become a large-size pain when
multiple versions of Beehive
35 matches
Mail list logo
