|
Werner Keil
Hi, As for the groupId, I am not sure, if Bill or others are worried about „javax.security“ being used by other Standards? JSR 374 and 367 (the first Version of that new Standard) share „javax.json“ https://search.maven.org/#search%7Cga%7C1%7Cjavax.json but JSON-B adds a „bind“ to the groupId. As for „javax.security“ https://search.maven.org/#search%7Cga%7C1%7Cjavax.security There have been many changes. After using the top Level groupId for some time, Things like javax.security.jacc or javax.security.auth.message evolved. There is a “security-api” from 2008 in the “javax.security” namespace, maybe that’s what Bill or others could be worried about? The new common naming convention adding the “javax” in front of every artifactId, would not cause a conflict, unless https://search.maven.org/remotecontent?filepath=javax/security/security-api/1.1-rev-1/security-api-1.1-rev-1.pom was ever to be updated to a new convention like “javax.security:javax.security-api” as well? It does however Sound like an older Version of JACC from the POM, so it is likely an older Version of javax.security.jacc-api anyway. If the groupId “javax.security” should not be used or shared by any JSR, “javax.security.enterprise” could be a good suggestion. I would not call a groupId “api” because every other JSR also pretty much defines that. With multiple packages only the Batch JSR ever even called a package “api”, but the groupId is “javax.batch” there for all artifacts. https://search.maven.org/#search%7Cga%7C1%7Cjavax.enterprise used by CDI and a few other standards could in theory also be an option if we were allowed to use “javax.enterprise.security” (the reverse of above) but that would slightly differ from the JSR proposal. Package-wise, without feeling a need to split the JARs (the Batch JSR did, but not sure, if we or users of the JSR would benefit from 2 API/SPI JARs here) could we also use “javax.annotation.security” or sub-packages As proposed in the JSR detail page for annotation types? Would that package be an option or what does Bill think about it? Kind Regards, Werner
From: Arjan TijmsSent: Friday, May 26, 2017 18:32 To: javaee-security-spec@javaee.groups.ioSubject: Re: [javaee-security-spec] Discussion: Artifact Group Id and PackageNames Hi, On Fri, May 26, 2017 at 6:01 PM, Will Hopkins <will.hopkins@...> wrote: Thanks for the replies.
Arjan -- what do you mean by javax.security is "the package we were given"? In what sense was it given?
By the original JSR submission. It listed the packages we could use. So the JSR was filed with that and the EC signed off on it.
With respect to the base package name:
· The javax.security.enterprise suggestion seems viable (although not all users of the API will be enterprise developers). · Arjan's suggestion of javax.security.api is also viable, but it does run into the problem that we're reserving an entire namespace -- all APIs for javax.security -- for ourselves, for all time. My main concern here is not to paint ourselves into a corner that constrains future JSRs.
The problem is perhaps that "javax" is basically seen as Java EE package, but Java SE in fact uses it too. IMHO Java EE should have been given its own exclusively package a long time ago, but it's no use arguing about that now as this ship has sailed. The name of the JSR is "Java EE Security API", so it says "all APIs for Java EE security". But the question is whether we're taking "javax" to mean "java ee" or not. If we're not, and in fact it is not, then perhaps javax.security.ee would be another option after javax.security.enterprise. That not all users may be enterprise users is perhaps not that important, it just reflects on the name of the JSR which is "Java EE Security API". · · What do people think about javax.security.jsapi, or javax.security.jesapi, to represent Java EE Security API? This is similar to what JACC did with javax.security.jacc.
Not really a big fan of "jesapi" I have to say, as it sounds a little cryptic, but if other people like it I won't be against it either. · It seems like the javax.security.identitystore.credentials package could really come up a level, to javax.security.credentials. If the credentials classes are really general purpose, they can and should be used by lots of code, not just by IdentityStore and consumers of IdentityStore.
I'm a bit impartial about that too and could live with both options ;) If I remember correctly javax.security.identitystore.credentials was originally proposed by Alex. · Similarly, I'm not a fan of having classes in the "root" package -- I'd like to see SecurityContext and related classes moved to javax.security.context. The CallerPrincipal class might warrant a "principals" package, or maybe it could live in "credentials".
There are examples in EE both for and against that. FacesContext lives in a .context package, but ServletContext lives in the root. My preference would be for the root though, as for a user facing API the SecurityContext would be the entry point. Then again, I would not be strongly against moving it out of the root. Thoughts? I apologize if I'm revisiting issues that were discussed and decided before, but as I'm looking at this stuff I feel like I need to at least ask the question(s).
I'm fairly sure the classes in the JSR root were discussed earlier as well, but fair enough ;)
Regards,
Will
On 05/26/2017 07:05 AM, Rudy De Busscher wrote: Arjan, With my remark, We don't do the *complete* security. I was referring to the fact that we only do it for Java EE, not SE for example. So we don't do the *complete* security for the JVM was a better comment. So subpackage is then more clear. On 26 May 2017 at 12:49, Arjan Tijms <arjan.tijms@...> wrote: Hi, We indeed don't do the complete security yet, although I think the plan was that we eventually would. The package we were given was javax.security. We could perhaps move everything to javax.security.api.*? As the current other packages (jaspic and jacc) are an spi. Jaspic even has it in its name: Java Authentication *SPI* for Containers. We can't change it now anymore, but javax.security.api.* and javax.security.spi.* with the latter containing jaspic and jacc would have been awesome. Curious what Werner has to say though, I remember him being most vocal about the current package arrangement. On Fri, May 26, 2017 at 9:51 AM, Rudy De Busscher <rdebusscher@...> wrote: Hi, A sub package of javax.security is maybe a better idea. We don't do the *complete* security. I agree that we need to avoid abbreviations as they are not as clear as the full name. On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote: Hi, I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote. Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote: Hi,
On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote: EG:
As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.
As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages.
As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security".
This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security".
Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)
To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents? I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages?
Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security?
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
Appreciate any and all feedback on this.
Will
-- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
Regards, Guillermo González de Agüero
-- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
|
|
|
"javax" was originally for "extensions"
that were not part of the JDK. Obviously that hasn't been the
case for quite some time. It was never intended only for Java EE.
I agree that we shouldn't put anything directly in
javax.security. Pick a sub-package name and put everything under
that, including sub-sub-packages as needed (but not too many).
javax.security.enterprise would be fine.
I'm not as thrilled with javax.security.ee or javax.security.jsapi
or javax.security.jesapi.
I agree with avoiding abbreviations when possible. If you can
come up with another word (not abbreviation) instead of
"enterprise" to use after javax.security, that would be worth
considering.
The use of javax.security in the JSR was a proposal, not a
requirement. Yes, it would've been better if this had been
worked out before the Public Review, but it's still not too late.
None of our specs say anything about Maven groupIds or
artifactIds, but I did write up a set of rules
that we've been trying to follow for our work.
Werner Keil wrote on 05/26/17 11:35 AM:
toggle quoted messageShow quoted text
Hi,
As for the groupId, I am
not sure, if Bill or others are worried about
„javax.security“ being used by other Standards?
JSR 374 and 367 (the first
Version of that new Standard) share „javax.json“
https://search.maven.org/#search%7Cga%7C1%7Cjavax.json
but JSON-B adds a „bind“ to
the groupId.
As for „javax.security“ https://search.maven.org/#search%7Cga%7C1%7Cjavax.security
There have been many
changes. After using the top Level groupId for some time,
Things like javax.security.jacc
or javax.security.auth.message
evolved.
There is a “security-api” from 2008 in the
“javax.security” namespace, maybe that’s what Bill or others
could be worried about? The new common naming convention
adding the “javax” in front of every artifactId, would not
cause a conflict, unless https://search.maven.org/remotecontent?filepath=javax/security/security-api/1.1-rev-1/security-api-1.1-rev-1.pom
was ever to be updated to a new convention like
“javax.security:javax.security-api” as well?
It does however Sound like
an older Version of JACC from the POM, so it is likely an
older Version of javax.security.jacc-api
anyway.
If the groupId “javax.security” should not
be used or shared by any JSR, “javax.security.enterprise”
could be a good suggestion. I would not call a groupId “api”
because every other JSR also pretty much defines that. With
multiple packages only the Batch JSR ever even called a
package “api”, but the groupId is “javax.batch” there for all
artifacts.
https://search.maven.org/#search%7Cga%7C1%7Cjavax.enterprise
used by CDI and a few other standards could in theory also be
an option if we were allowed to use
“javax.enterprise.security” (the reverse of above) but that
would slightly differ from the JSR proposal.
Package-wise, without feeling a need to
split the JARs (the Batch JSR did, but not sure, if we or
users of the JSR would benefit from 2 API/SPI JARs here) could
we also use
“javax.annotation.security”
or sub-packages
As proposed in the JSR detail page for
annotation types?
Would that package be an option or what
does Bill think about it?
Kind Regards,
Werner
Hi,
On Fri, May 26, 2017 at 6:01 PM, Will
Hopkins <will.hopkins@...>
wrote:
Thanks
for the replies.
Arjan -- what do you mean by javax.security is "the
package we were given"? In what sense was it given?
By the original JSR submission. It
listed the packages we could use. So the JSR was filed
with that and the EC signed off on it.
With respect to the base package name:
· The
javax.security.enterprise suggestion seems viable
(although not all users of the API will be
enterprise developers).
· Arjan's
suggestion of javax.security.api is also viable, but
it does run into the problem that we're reserving an
entire namespace -- all APIs for javax.security --
for ourselves, for all time. My main concern here is
not to paint ourselves into a corner that constrains
future JSRs.
The problem is perhaps that "javax"
is basically seen as Java EE package, but Java SE in
fact uses it too. IMHO Java EE should have been given
its own exclusively package a long time ago, but it's
no use arguing about that now as this ship has sailed.
The name of the JSR is "Java EE
Security API", so it says "all APIs for Java EE
security". But the question is whether we're taking
"javax" to mean "java ee" or not.
If we're not, and in fact it is
not, then perhaps javax.security.ee
would be another option after
javax.security.enterprise. That not all users may be
enterprise users is perhaps not that important, it
just reflects on the name of the JSR which is "Java EE
Security API".
·
· What
do people think about javax.security.jsapi, or
javax.security.jesapi, to represent Java EE Security
API? This is similar to what JACC did with
javax.security.jacc.
Not really a big fan of "jesapi" I
have to say, as it sounds a little cryptic, but if
other people like it I won't be against it either.
· It
seems like the
javax.security.identitystore.credentials package
could really come up a level, to
javax.security.credentials. If the credentials
classes are really general purpose, they can and
should be used by lots of code, not just by
IdentityStore and consumers of IdentityStore.
I'm a bit impartial about that too
and could live with both options ;) If I remember
correctly javax.security.identitystore.credentials was
originally proposed by Alex.
· Similarly,
I'm not a fan of having classes in the "root"
package -- I'd like to see SecurityContext and
related classes moved to javax.security.context. The
CallerPrincipal class might warrant a "principals"
package, or maybe it could live in "credentials".
There are examples in EE both for
and against that. FacesContext lives in a .context
package, but ServletContext lives in the root.
My preference would be for the root
though, as for a user facing API the SecurityContext
would be the entry point. Then again, I would not be
strongly against moving it out of the root.
Thoughts?
I apologize if I'm revisiting issues that were
discussed and decided before, but as I'm looking at
this stuff I feel like I need to at least ask the
question(s).
I'm fairly sure the classes in the
JSR root were discussed earlier as well, but fair
enough ;)
Regards,
Will
On
05/26/2017 07:05 AM, Rudy De Busscher wrote:
Arjan,
With my remark, We don't do
the *complete* security. I was referring
to the fact that we only do it for Java
EE, not SE for example.
So we don't do
the *complete* security for the JVM was a better
comment. So subpackage is then more
clear.
On 26 May 2017
at 12:49, Arjan Tijms <arjan.tijms@...>
wrote:
Hi,
We indeed
don't do the complete security yet,
although I think the plan was that
we eventually would.
The
package we were given was
javax.security. We could perhaps
move everything to
javax.security.api.*? As the current
other packages (jaspic and jacc) are
an spi. Jaspic even has it in its
name: Java Authentication *SPI* for
Containers.
We can't
change it now anymore, but
javax.security.api.* and
javax.security.spi.* with the latter
containing jaspic and jacc would
have been awesome.
Curious
what Werner has to say though, I
remember him being most vocal about
the current package arrangement.
On Fri,
May 26, 2017 at 9:51 AM, Rudy De
Busscher <rdebusscher@...>
wrote:
Hi,
A
sub package of javax.security
is maybe a better idea. We
don't do the *complete*
security.
I
agree that we need to avoid
abbreviations as they are not
as clear as the full name.
On
26 May 2017 at 08:38,
Arjan Tijms <arjan.tijms@...>
wrote:
Hi,
I
remember there was
quite some
discussion about the
package names in the
EG and the current
ones are the results
of a broad consensus
including a vote.
Indeed,
the longer
non-abbrivated names
are probably better.
They give the API
IMO a more fresh and
modern feel.
Abbreviating to
(very) short names
reminds me quite a
bit of old AS/400
code. "AuthMech" in
particular sounds a
bit like a Japanese
robot suit :P
On Fri, May 26, 2017 at 7:56 AM, Guillermo
González de
Agüero <z06.guillermo@...>
wrote:
Hi,
On Fri, May 26, 2017 at 1:24 AM, Will Hopkins
<will.hopkins@...>
wrote:
EG:
As part of
getting ready
to publish our
artifacts to maven.java.net,
I've been
looking at the
following
naming
guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html.
As well, one
of Bill's
comments on
the EDR spec
was that he
thought there
were too many
different
packages.
As a result, I
wonder if we
should rethink
the current
package
structure. In
particular,
I'm concerned
about our use
of the
"javax.security"
package, which
also implies
an artifact
groupId of
"javax.security".
This package
name is the
"root" of all
Java EE and
Java SE
security
packages, with
the exception
of a few Java
SE packages at
and below
"java.security".
Previous JSRs,
including JACC
and JASPIC,
have chosen to
use packages
under
javax.security,
but not place
any classes in
javax.security
itself. I
think that
makes sense,
as it doesn't
"hog" the
namespace.
It's true that
JSR-375 is
meant to be
the home for
all things
Java EE
security, but
as a practical
matter we
might not want
to reserve
java.security
for our
exclusive use
for all time.
Moving
everything
under some
common
sub-package of
java.security
seems like a
good idea --
although I'll
grant that no
obvious name
for that
sub-package
springs
immediately to
mind ...
What
about javax.security.enterprise?
The word
enterprise is
already used
in CDI (e.g.:
javax.enterprise.context)
To Bill's
comment about
the number of
packages, how
would people
feel about
consolidating
the
"annotation"
sub-packages
with their
parents?
I.e., move the
annotations
into the
javax.security.authentication.mechanism.http
and
java.security.identitystore
packages and
eliminate the
sub-packages?
Lastly, would
a
shorter-but-still-specific
name for
javax.security.authentication.mechanism.http
make sense?
Perhaps
java.security.http.authmech?
Or a slightly
shorter
package name
for Identity
Store:
javax.security.idstore?
And should we
make a
javax.security.context
package so
that
SecurityContext
and related
classes can
move out of
javax.security?
I strongly prefer longer but self-explanatory
package names.
I see they
easier to
find, and once
they are
imported, I
only have to
deal with the
class name
anyway, so a
long package
name is not a
problem at
all.
Appreciate any
and all
feedback on
this.
Will
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
Regards,
Guillermo González de Agüero
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
|
|
|
In light of Bill's comments, are we agreed on
javax.security.enterprise?
Does anyone have an alternative proposal?
On 05/26/2017 04:08 PM, Bill Shannon
wrote:
"javax" was originally for
"extensions" that were not part of the JDK. Obviously that
hasn't been the case for quite some time. It was never intended
only for Java EE.
I agree that we shouldn't put anything directly in
javax.security. Pick a sub-package name and put everything
under that, including sub-sub-packages as needed (but not too
many).
javax.security.enterprise would be fine.
I'm not as thrilled with javax.security.ee or
javax.security.jsapi or javax.security.jesapi.
I agree with avoiding abbreviations when possible. If you can
come up with another word (not abbreviation) instead of
"enterprise" to use after javax.security, that would be worth
considering.
The use of javax.security in the JSR was a proposal, not
a requirement. Yes, it would've been better if this had
been worked out before the Public Review, but it's still not too
late.
None of our specs say anything about Maven groupIds or
artifactIds, but I did write up a set of rules that we've been trying to
follow for our work.
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
|
|
|
Arjan Tijms
|
|
|
Having heard support from several people, and no objections, I'm
going to move forward with creating the javax.security.enterprise
groupId in maven.java.net, and migrating the API package names.
If anyone *does* object, now is the time to let me know.
Regards,
Will
On 05/26/2017 07:43 PM, Arjan Tijms
wrote:
Hi,
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803
|
|
|
