I think we need to refactor:
- config-api mixes two distinct things: generic Glassfish V3
*framework* support for config eg GlassFishConfigBean
- specific interfaces for config eg the 'serverbeans' interfaces for
elements in domain.xml
That structure is a mistake. It has forced me (see below) to make
config-api depend on amx-impl (so that that the server beans code can
use @AMXInfo). But that's not right at all for the framework code,
upon which amx-impl depends or will depend. And the AMXInfo is
general, not restricted to config.
I'm not sure how to refactor this, but I am STUCK until we refactor
something.
Lloyd
On Feb 14, 2008, at 9:47 AM, Lloyd L Chambers wrote:
> Jerome,
>
> I updated this morning, and I'm seeing this cyclic dependency:
>
> [INFO] The projects in the reactor contain a cyclic reference: Edge
> between 'Vertex{label='org.glassfish.admin:config-api'}' and 'Vertex
> {label='org.glassfish.common:amx-impl'}' introduces to cycle in the
> graph org.glassfish.common:amx-impl --> org.glassfish.common:common-
> util --> org.glassfish.common:glassfish-api -->
> org.glassfish.admin:config-api --> org.glassfish.common:amx-impl
>
> I'm not sure what is changed, but I had put a dependency from
> config-api on amx-impl because the
> com.sun.enterprise.config.serverbeans interfaces (like Domain.java
> and HttpListener.java) must be annoted with @AMXInfo.
>
> The problem seems to be that glassfish-api depends on config-api,
> which is completely wrong IMO, at least when the serverbeans stuff
> is included there.
>
>
> ---
> Lloyd L Chambers
> lloyd.chambers_at_sun.com
> Sun Microsystems, Inc
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc