Thanks for the insight. I fully agree.

On Jul 30, 2008, at 6:37 PM, Howard Lewis Ship wrote:

Part of Tapestry 5 is "simplify, simplify".  HiveMind had qualified
service ids and service visibility, but with the move to Tapestry 5,
prompted by other containers such as Guice, I started to question why
some of those features are in place.  I found that all the "private"
services were in one of the internal packages, for example.  And,
ultimately, I didn't want to wall users off from any of the
functionality, they should take "internal" to be a very important
caution.

The visibility concerns also led to some unwanted ambiguities around
OrderedConfigurations and decorators. How can you order things when
the other ids are not known?  Does "before:*" mean before all, or just
before the objects whose ids are visible?  Etc.

On Wed, Jul 30, 2008 at 6:57 AM, Michael Zehender
<[EMAIL PROTECTED]> wrote:
May I ask why the decision was made to strip it out?

I'm sorry, I don't want to be rude but I'd just like to know. Maybe
I'd need to redesign a few things if I understand ...

Thanks,
Michael

2008/7/30, Howard Lewis Ship <[EMAIL PROTECTED]>:
This is actually a feature of Tapestry IoC that was stripped out long
ago (that is, private services within modules).  HiveMind, the
precursor to Tapestry 5 IoC, has this feature.

On Wed, Jul 30, 2008 at 1:56 AM, Michael Zehender
<[EMAIL PROTECTED]> wrote:
Hello Renat,

I'm currently building a product that will integrate with 3rd party modules.

I want them to use only the published services to prevent them of developing
bad hacks using the
Internal Services instead, which might change from version to version. I
want to provide backwards
compatibility for the published services only and don't want to run into
conflicts because of them
using internal services.

These 3rd party modules 'depend' on the products core services, they also
contribute to the
configuration of some services (but these are also published).

Michael

On Jul 30, 2008, at 10:26 AM, Renat Zubairov wrote:

Hello Michael,

Would would be the usecases for this feature? Why would you need it?
Are you also planning to have versions for the modules?
How are dependencies between the modules are resolved?

Renat

2008/7/30 Michael Zehender <[EMAIL PROTECTED]>:

Hi,

I'm just looking for a way to configure the visibility of services within
the IoC container. The target would be
have module internal services i.e. these internal services can be
injected
to services within the same module only.

A short example to illustrate, in the MyCoreModule I want to hide the
configuration reader and the category factory:

@SubModule( {
    MySubModule.class
})
@Marker(MyCore.class)
public class MyCoreModule
{
    public static void bind(ServiceBinder binder)
    {
            binder.bind(CategoryFactory.class,
CategoryFactoryImpl.class).private();
            binder.bind(ConfigurationReader.class,
ConfigurationReaderImpl.class).private();
            binder.bind(ConfigurationProvider.class,
ConfigurationProviderImpl.class);
            binder.bind(ConfigurationStartup.class,
ConfigurationStartupImpl.class);
binder.bind(SystemControl.class, SystemControlImpl.class);
    }

    @EagerLoad
    public static Startup buildStartup(final List<StartupItem>
startupItems, Logger logger)
    {
            return new StartupImpl(logger, startupItems);
    }
}

Now we have a second Module:

@Marker(MySub.class)
public class MySubModule
{
    public static void bind(ServiceBinder binder)
    {
            // ...
    }

public static SomeService buildSomeService(CategoryFactory factory)
    {
// shouldn't be work ! a service not found exception would
be
the nicest ...
            return ...;
    }
}

Is this possible? If not is there a plan to implement it?

Thanks,
Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Best regards,
Renat Zubairov

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to