Modules and hidden packages
by David M. Lloyd
There is a mechanism in JBoss Modules to support packages which are not
visible to consumers of a module. The idea is to come up with an easy
convention so that we can put module-private APIs and classes in one
place that is visible from multiple packages, without exposing or
documenting these packages.
Until 1.2, the only way available to do this for statically defined
modules was to add an export filter in your module.xml via the <exports>
element to exclude the specific package directories that are hidden.
Starting in 1.2, you can also create a series of packages whose first
segment is "_private". These packages will automatically be excluded
from the exported paths list.
What I'd like to propose is:
1) For any given module, all generated JavaDoc should exclude packages
under the _private hierarchy.
2) For any module which does i18n logging, all logging messages should
be consolidated in one or more (but preferably one) interface(s) stored
in a public _private.org.yourproject.YourInterface.
3) Once the new name is announced, I think we should break up our main
logging IDs into per-subsystem categories. For example, "XXEE" for EE,
"XXEJB" for EJB, etc., each with their own numerical space and message
interface. These two changes should put an end to our log message ID
fragmentation problems and give us a (one-time only!) chance to clean up
this mess.
4) Projects that wish to exploit this mechanism can do so, noting that
they should use "_private.org.yourproject" as a package prefix instead
of just putting things directly under "_private" (to avoid conflicts
when JARs are used on a flat class path).
Flame on!
--
- DML
12 years, 1 month
Time to drop the 3 from EJB3?
by Darran Lofthouse
Just a quick thought, is it now time to drop the 3 from EJB3?
The 3 has lived on in the namespace for the subsystem
"urn:jboss:domain:ejb3:2.0" but as AS8 != EAP 6 maybe we can cope with
the 3 going.
Regards,
Darran Lofthouse.
12 years, 1 month
Re: [jboss-as7-dev] Naming Issues
by Eduardo Martins
On Tue, 2013-04-02 at 08:47 +1100, Stuart Douglas wrote:
> >
> > 4. Other issues
> >
> > There are other issues, for instance rebind does unbind+bind, and this would mean that any state (such as env on the old entry) is lost, msc deps get screwed, etc. but I did not check these with testing yet, and we can probably target these later.
>
> I am not sure what you mean here.
This is actually a bug I think, on rebind we do unbind and then bind,
which means get the existent msc service controller and stop it
(unbind), and then install a new msc service (bind). Shouldn't instead
we just replace the managed ref factory within the existent service?
--E
12 years, 1 month
Re: [jboss-as7-dev] Naming Issues
by Stuart Douglas
Eduardo Martins wrote:
> Hi all, I have been looking at whole code of service based naming stores, and we have several more issues (beyond the injection without lookup), some which may motivate deep changes on the logic:
>
> 1. Subcontext created not stored
>
> InitialContext context = new InitialContext();
> context.createSubcontext("a");
> Context a = (Context) context.lookup("a");
>
> The lookup above fails, and this due to not creating sub contexts on the store. I discussed this briefly with David last week, seems a bug, but it could also be done this way as a feature. As it is now implemented, a context only exists if there a child entry.
> Obviously by not having sub contexts we also fail on managing sub contexts environments, it is always null, when it should start as the parent context's one, and store changes on its own.
>
> Note that this implementation choice was clearly made on purpose, there is no destroyContext() impl at all (other than name validation and check for writable store type).
> This implementation choice saves the storing of a few msc services, but that also means no dependencies to contexts will exist
>
There are some cases where contexts are explicitly bound, such as in the
case of java:comp/env (which must be available for lookup even if it is
empty). We should do the same thing here.
> 2. (Re)Bind without parent context
>
> Context a = null;
> InitialContext context = new InitialContext();
> try {
> a = (Context) context.lookup("a");
> } catch (NameNotFoundException e) {
> context.bind("a/b",new Object());
> }
>
> The bind above will succeed, i.e. we allow binds without parent context, but according to Context javadocs bind or rebind require that the parent context exists.
>
This was a deliberate decision. Unless it is actually causing someone
problems we do not need to change this.
> 3. Linkrefs madness
>
> Currently the lookup logic, wrt links is more or less: lookup a msc service with the provided name, and if nothing found look for a parent msc service, which if exists and is a link then we try again with link value + remaining name. Then on bind we do not follow links, we bind directly to the provided name, so:
>
> InitialContext context = new InitialContext();
> context.bind("a1",new LinkRef("a2"));
> context.bind(new CompositeName("a2","b"),new Object());
> context.bind(new CompositeName("a1","b"),new Object());
> context.lookup(new CompositeName("a1","b"));
> context.lookup(new CompositeName("a2","b"));
>
> This will bind 2 values to the same "logic" name, and both lookups will work, yet return the different values. To fix this on bind we should first lookup the parent context, which if follows links correctly, would have failed context.bind(new CompositeName("a1","b"),new Object())
>
> There are also obvious link related issues on msc deps: if somehitng is bound using a name that contains a link, lookup deps will only work if use the name used in bind. Fixing this part may be scary, msc would need to know that when a link is bound, deps to both linksource/x and linktarget/y may become satisfied. Still on msc topic, rebind support is also a problem, since we can't change deps
>
This looks like we are not checking the parent context at all, which is
something we should fix to prevent children being bound as children of
other non-context bindings.
> 4. Other issues
>
> There are other issues, for instance rebind does unbind+bind, and this would mean that any state (such as env on the old entry) is lost, msc deps get screwed, etc. but I did not check these with testing yet, and we can probably target these later.
>
I am not sure what you mean here.
> 5. So, how do we fix all of this?
>
> Well, for a start should we fix it? I know some people may want to avoid these kind of changes, but naming is not quite something that is going away any soon, and imho our naming is broken at so many ways...
Not really. For the most part these are fairly minor issues, this same
code has been in use for a long time now, if these were a major problems
that required a complete redesign then we would have heard more complaints.
>
> IF we go for fixing it, start by adding and requiring the missing contexts, while at same time provide an option for create these automatically on bind, to be used on everything besides direct jndi app code, avoiding changes on binding code everywhere on AS projects.
I really don't think this is necessary. Even though this goes against
the javadoc it is not causing problems for users, and it is basically a
feature that makes JNDI binding a lot easier to use.
>
> And then reverse the bind/lookup logic wrt links, first lookup the parent, to follow links properly, and only then bind/lookup the terminal part of the name. Wrt implementation this would also mean that we probably would make it much faster by having each context with a map of terminal name childs, dunno about memory... Currently we have in each store a ConcurrentSkipListSet, and use lower/ceiling functionally to navigate through it.
>
We should probably be looking up each context when performing a bind.
This should not require any underlying change in the data structures
used, rather the name should just be separated into components, and then
each component looked up. bind() performance is not a big deal, as it
generally only happens at application startup.
> Wrt MSC, we could for a start try to no fix all at once, as I have been saying to David, thus ignore the existent of links targets, BUT ensuring all understand the limitations for dependencies if links are used. Anyway I believe David wants to go further so I will just leave it for him to comment.
>
>
I think we just need an extra namespace that ignores service
dependencies, that it always looked up via straight JNDI lookup. We
should also consider just using a lookup in LookupInjectionSource, but I
would like to see how it impacts performance first.
Stuart
> --E
>
>
12 years, 1 month
