Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The MessageStoreSender.java class defines unwanted XML elements MessageStoreSenderErrorStorage and MessageStoreSenderMessageLog #155

Open
mhdirkse opened this issue Apr 13, 2023 · 1 comment

Comments

@mhdirkse
Copy link
Contributor

Java class MessageStoreSender.java should define XML elements MessageStoreErrorSender and MessageStoreSender, but in addition the elements MessageStoreSenderErrorStorage and MessageStoreSenderMessageLog are defined. These extra elements should not be used by Frank developers and hence they should not appear in the Frank!Doc.

These elements appear because Java class MessageStoreSender inherits class JdbcTransactionalStorage for technical reasons. The existence of error stores and message logs is expressed by element roles (ITransactionalStorage, "errorStorage") and (ITransactionalStorage, "messageLog"). There is a FrankElement for Java class MessageStoreSender. The XML tags are calculated from all the ElementRoles to which MessageStoreSender belongs. Because of the inheritence, these ElementRole-s include (ITransactionalStorage, "errorStorage") and (ITransactionalStorage, "messageLog"). This is why the unwanted XML elements appear.

One way to solve this is to introduce a new annotation in the Frank!Doc that says that an inheritance relation is only technical. Then the logic that defines ElementType-s should exclude members based on this annotation. As a consequence the ElementRole-s that include these ElementType-s do not include the unwanted members and hence the unwanted XML elements are not defined.

@mhdirkse
Copy link
Contributor Author

Initially I thought about this issue as a feature request - we need to exclude MessageStoreSender from a type. However, the @FrankDocGroup annotation has logic not only to add ElementType-s to groups but also to restrict FrankElement-s to groups. This logic is used to restrict MessageStoreSender to the group of Senders and exclude it from the group of TransactionalStorages.

There are two ways that syntax 2 names of FrankElement-s are calculated. First, the JSON lists for each group the element types and for each element type the members. The members of the element type are calculated here taking into account the @FrankDocGroup annotations. However, at the page of a FrankElement the syntax 2 names are calculated another way. Here, the ElementRole-s are considered which depend on the ElementType-s. @FrankDocGroup annotations do not remove FrankElement-s from ElementType-s so here the @FrankDocGroup restrictions are ignored.

I propose that we simplify the behavior of the @FrankDocGroup annotation to only add members to groups - no restriction. Only the members of ElementRole-s and ElementType-s should determine the syntax 2 names. We need an annotation to remove FrankElement-s from ElementTypes.

That new annotation could be placed on a FrankElement, something like @ExcludeFromType(ITransactionalStorage.class). Or we could have an annotation on the Java interface, for example on ITransactionalStorage: @ExcludeMembers({MessageStoreSender.class}).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant